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A method and apparatus are provided 
for compliance checking in a trust-management 
system. A request r, a policy assertion (/b, 
POLICY), and n-1 credential assertions (/j, si), 
Sn-\) are received, each credential 
assertion comprising a credential function f and 
a credential source s\. Each assertion may be 
monotonic, authentic, and locally bounded. An 
acceptance record set S is initialized to {(A, 
A, /?)}, where A represents a distinguished null 
string, and R represents the request r. Each 
assertion (fu s\) y where i represents the integers 
from n-1 to 0, is run and the result is added 
to the acceptance record set S. This is repeated 
mn times, where m represents a number greater 
than 1 , and an acceptance is output if any of the 
results in the acceptance record set S comprise 
an acceptance record (0, POLICY, R). 
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METHOD AND APPARATUS FOR COMPLIANCE 
CHECKING IN A TRUST-MANAGEMENT SYSTEM 



CROSS REFERENCE TO RELATED APPLICATIONS 

The present application claims the benefit of U.S. provisional 
patent application Serial No. 60/074,848 entitled "Compliance 
1 0 Checking in the Policy Maker Trust Management System" to 

Matthew A. Blaze, Joan Feigenbaum and Martin J. Strauss and filed 
on February 17, 1998. 
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FIELD OF THE INVENTION 

The invention relates to trust-management systems. More 
particularly, the invention relates to a method and apparatus for 
compliance checking in a trust-management system. 



20 COPYRIGHT NOTICE 

, A portion of the disclosure of this patent document contains 
material which is subject to copyright protection. The copyright 
owner has no objection to the facsimile reproduction by anyone of the 
25 patent document or patent disclosure as it appears in the Patent and 

Trademark Office patent file or records, but otherwise reserves all 
copyright rights whatsoever. 
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BACKGROUND OF THE INVENTION 

Emerging electronic commerce services that use public-key 
cryptography on a mass-market scale require sophisticated 
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mechanisms for managing trust. For example, a service that receives 
a signed request for action may need to answer a basic question: "is 
the key used to sign this request authorized to take this action? 1 ' In 
some services, the question may be more complicated, requiring 
5 techniques for formulating security policies and security credentials, 

determining whether particular sets of credentials satisfy the relevant 
policies, and deferring trust to third parties. Matt Blaze, Joan 
Feigenbaum and Jack Lacy, "Decentralized Trust Management," 
Proc. IEEE Conference on Security and Privacy (May 1996) 
10 (hereinafter "Blaze, Feigenbaum and Lacy"), the entire contents of 

which is hereby incorporated by reference, discloses such a trust- 
management problem as a component of network services and 
describes a general tool for addressing it, the "PolicyMaker" trust- 
management system. 

1 5 As will be explained, the heart of the trust-management 

system is an algorithm for compliance checking. The inputs to the 
compliance checker are a "request," a "policy" and a set of 
"credentials." The compliance checker returns a "yes" (acceptance) 
or a "no" (rejection), depending on whether the credentials constitute 

20 a proof that the request complies with the policy. Thus, a central 

challenge in trust management is to find an appropriate notion of 
"proof and an efficient algorithm for checking proofs of compliance. 

Unfortunately, the compliance-checking problem may be 
mathematically undecidable in its most general form. Moreover, the 

25 compliance-checking problem is still non-deterministic polynomial 

time (NP) hard even when restricted in several natural ways. 

Blaze, Feigenbaum and Lacy discloses the trust-management 
problem as a distinct and important component of security in network 
services. Aspects of the trust-management problem include 

30 formulation of policies and credentials, deferral of trust to third 
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parties, and a mechanism for "proving" that a request, supported by 
one or more credentials, complies with a policy. A comprehensive 
approach to trust management independent of the needs of any 
particular product or service is disclosed along with a trust- 
management system that embodies the approach. 

In particular, the PolicyMaker system comprises policies, 
credentials, and trust relationships that are expressed as functions or 
programs (or parts of programs) in a "safe" programming language. 
A common language for policies, credentials, and relationships makes 
it possible for applications to handle security in a comprehensive, 
consistent, and largely transparent manner. 

The PolicyMaker system is also expressive enough to support 
the complex trust relationships that can occur in large-scale network 
applications. At the same time, simple and standard policies, 
credentials, and relationships can be expressed succinctly and 
comprehensibly. 

The Policy Maker system provides local control of trust 
relationships. Each party in the network can decide in each 
transaction whether to accept the credential presented by a second 
party or, alternatively, which third party it should ask for additional 
credentials. Local control of trust relationships, as opposed to a top- 
down centralized approach, eliminates the need for the assumption of 
a globally known, monolithic hierarchy of "certifying authorities." 
Such hierarchies do not scale easily beyond single "communities of 
interest" in which trust can be defined unconditionally from the top 
down. 

The PolicyMaker mechanism for checking that a set of 
credentials proves that a requested action complies with local policy 
does not depend on the semantics of the application-specific request, 
credentials or policy. This allows different applications with varying 

— » 
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policy requirements to share a credential base and a trust- 
management infrastructure. 

Three examples of application-specific requests, and local 
policies with which they may need to comply, will now be described. 
5 Although individually the examples are of limited complexity, 

collectively they demonstrate that an expressive, flexible notion of 
"proof of compliance" is needed. 

As a first example, consider an e-mail system in which 
messages arrive with headers that include, among other things, the 

10 sender's name, the sender's public key, and a digital signature. When 

a recipient's e-mail reader processes an incoming message, it uses the 
public key to verify that the message and the signature go together 
(i.e., an adversary has not spliced a signature from another message 
onto this message). The recipient may also be concerned about 

1 5 whether the name and public key go together. In other words, could 

an adversary have taken a legitimate message-signature pair that he 
produced with this own signing key and then attached to it his public 
key and someone else's name? To address this concern, the recipient 
needs a policy that determines which name-key pairs are trustworthy. 

20 Because signed messages may regularly arrive from senders that he 

has never met, a simple private database of name-key pairs may not 
be sufficient. By way of example, a plausible policy might include 
the following: 

( 1 ) He maintains private copies of the name-key pairs (N } , 
25 PK } ) and (N 2 , PK 2 )^ A reasonable interpretation of this part of the 

policy is that he knows the people named N } and personally and 
can get reliable copies of the public keys directly from them. 

(2) He accepts "chains of trust" of length one or two. An arc 
in a chain of trust is a "certificate" of the form (PK h (N p PKj), S). 

30 This is interpreted to means that the owner N t of PK i vouches for the 
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binding between the name Nj and the public key PKj. This can also 
mean that TV, attests that Nj is trusted to provide certificates of this 
form. The party N; signs (Nj, PKj) with his private key and the 
resulting signature S, 

(3) He insists that there be two disjoint chains of trust from 
the keys that he maintains privately to the name-key pair that arrives 
with a signed message. 

As a second example, consider a loan request submitted to an 
electronic banking system. Such a request might contain, among 
other things, the name of the requester and the amount requested. A 
plausible policy for approval of such loans might take the following 
form: 

(1) Two approvals are needed from loans of less than $5,000. 
Three approvals are needed for loans of between $5,000 and $10,000. 
Loans of more than $10,000 are not handled by this automated loan- 
processing system. 

(2) The head of the loan division must authorize approvers' 
public keys. The division head's public key is currently PK 3 . This 
key expires on December 3 1 , 1 998. 

As a third example, consider a typical request for action in a 
web-browsing system, such as "view URL 

http://www.research.att.com/." In constructing a viewing policy, a 
user may decide what type of metadata, or labels, she wants 
documents to have before viewing them, and whom she trusts to label 
documents. The user may insist that documents be rated (S < 2, L < 
2, V= 0, N < 2) on the sex (S), language (L), violence (V) and nudity 
(N) scales, respectively. She may trust self-labeling by some 
companies or any labels approved by certain companies. 

Previous work on "protection systems" is loosely related to 
the concept of a trust-management system. Recent work that is 

5 
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similarly related to the present invention can be found in, for 
example, T. Y. C. Woo and S. S. Lam, ^Authorization in distributed 
Systems: A New Approach," Journal of Computer Security 2 pp. 107- 
36 (1993). In addition, protection systems, as described by D. 
5 Denning, Cryptography and Data Security . Addison- Wesley, Reading 

(1982), address a similar, but not identical, problem. 

M. A. Harrison, W. L. Ruzzo and J. D. Ullman, "Protection in 
Operating Systems," Communications of the ACM 19, pp. 461-71 
(1976) analyze a general protection system based on the "access 

10 matrix" model. In matrix A 9 indexed by subjects and objects, cell A so 

records the rights of subject S over the object o\ a set of transition 
rules describes the rights needed as preconditions to modify A and the 
specific ways in which A can be modified, by creating subjects and 
objects or by entering or deleting rights at a single cell. Harrison et 

15 al. showed that given (1) an initial state A 0 ; (2) a set A of transition 

rules and (3) a right r, it is undecidable whether some sequence 5 
... 6. e A transforms A 0 such that 6 enters r into a cell not 
previously containing r, i.e., whether it is possible for some subject, 
not having right r over some object, ever to gain that right. On the 

20 other hand, Harrison et al. identify several possible restrictions on A 

and give decision algorithms for input subject to one of these 
restrictions. One restriction they consider yields a PSPACE-complete 
problem. 

Independently, A. K. Jones, R. J. Lipton and L. Snyder, "A 
25 Linear Time Algorithm for Deciding Security, Proceedings of the 

Symposium on Foundations of Computer Science," IEEE Computer 
Society Press . Los Alamitos, pp. 33-41 (1 976) define and analyze 
"take-grant" directed-graph systems. Subjects and objects are nodes; 
an arc a from node n } to n 2 is labeled by the set of rights w ( has over 
30 n 2 . If subject «| has the "take" right over n 2 ? and n 2 has some right r 
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over w 3 , then a legal transition is for n x to take right r over n y 
Similarly, if the subject n x has the "grant" right over n 2 , and n x has 
some right r over w 3 , then a legal transaction is for «, to grant right r 
over w 3 to n 2 . Besides these transitions, subjects can create new 
nodes and remove their own rights over their immediate successors. 
Although rights are constrained to flow only via take-grant paths, 
take-grant systems do model non trivial applications. 

Jones et al. asked whether a right r over a node x possessed by 
n ]9 but not possessed by n 2 , could ever be acquired by w 2 . They 
showed that this question can be decided in time linear in the original 
graph by depth-first search. Thus, Denning concludes that although 
safety in protection systems is usually undecidable, the results in, for 
example, Jones et al. demonstrate that safety can be decided feasibly 
in systems with sets of transition rules from a restricted though non- 
trivial set. The related results on compliance-checking described 
herein provide additional support for Denning' s conclusion. 

Having reviewed the basics of "protection systems," it can be 
seen why they address a similar but not identical problem to the one 
addressed by the compliance-checking algorithm described herein. In 
the protection system world, there is a relatively small set of 
potentially dangerous actions that could ever be performed, and this 
set is agreed upon in advance by all parties involved. A data 
structure, such as an access matrix, records which parties are allowed 
to take which actions. This data structure is pre-computed offline, 
and, as requests for action arrive, their legitimacy is decided via a 
lookup operation in this data structure. "Transition rules" that change 
the data structure are applied infrequently, and they are implemented 
by a different mechanism and in a separate system module from the 
ones that handle individual requests for action. 



7 
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In the trust-management system world, the set of potentially 
dangerous actions is large, dynamic, and not known in advance. A 
system provides a general notion of "proof of compliance" for use by 
diverse applications that require trust policies. The users of these 
5 applications and the semantics of their actions and policies are not 

even known to the compliance-checking algorithm; hence it is not 
possible for all parties to agree in advance on a domain of discourse 
for all potentially dangerous actions. The compliance-checking 
question "is request r authorized by policy P and credential set C?" is 

1 0 analogous to the question u can subject S eventually obtain right r by 

transition rules A" in the protection system world. However, a single 
instance of request processing, especially one that involves deferral of 
trust, can require a moderately complex computation and not just a 
lookup in a pre-computed data structure. Accordingly, an 

15 embodiment of the present invention formalizes the complexity of a 

general-purpose, working system for processing requests of this 
nature. In summary, a general purpose trust-management system is, 
very roughly speaking, a meta-system in the protection system 
framework. 

20 In addition, an application-independent notion of compliance 

checking can be useful and can enhance security. Any product or 
service that requires proof that a requested transaction complies with 
a policy could implement a special-purpose compliance checker from 
scratch. One important advantage of a general purpose compliance 

25 checker is the soundness and reliability of both the design and the 

implementation of the compliance checker. Formalizing the notion of 
"credentials proving that a request complies with a policy" involves 
subtlety and detail. It is easy to get wrong, and an application 
developer who sets out to implement something simple to avoid an 

30 "overly complicated" syntax of a general-purpose compliance checker 
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is likely to find that: (1) she has underestimated the complexity of the 
application's needs for expressiveness and proof or (2) her special- 
purpose compliance checker is not turning out so simple. 

A general-purpose notion of proof of compliance can be 
5 explained, formalized, proven correct, and implemented in a standard 

package, to free developers of individual applications from the need 
to reinvent the system. Applications that use a standard compliance 
checker can be assured that the answer returned for any given input 
(such as a request, a policy, and a set of credentials) depends on the 

1 0 input, and not on any implicit policy decisions (or bugs) in the design 

or implementation of the compliance checker. As policies and 
credentials become more diverse and complex, the issue of assuring 
correctness will become even more important, and modularity of 
function (with a clean separation between the role of the application 

1 5 and the role of the compliance checker) will make further 

development more manageable. 

Two important sources of complexity that are often 
underestimated are delegation and cryptography. Products and 
services that need a notion of "credential" almost always have some 

20 notion of "delegation" of the authority to issue credentials. The 

simplest case, unconditional delegation, is easily-handled by a 
special-purpose mechanism. However, if the product or service 
grows in popularity and starts to be used in ways that were not 
foreseen when originally deployed, delegation can quickly become 

25 more complex, and a special-purpose language that restricts the types 

of conditional delegation that the service can use may become an 
impediment to widespread and imaginative use. 

The general framework for compliance checking avoids this 
by letting delegation be described by ordinary programs. Similarly, 

30 digital signatures and other browsers can be designed to 
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accommodate "safe surfing" policies configurable by parents, but 
may not initially involve cryptographic functions. If the application is 
subsequently integrated into the wider world of electronic commerce, 
however, cryptography may be desired and cryptographic credentials, 
5 such as public-key certificates, may need to be incorporated into the 

application's notion of proof of compliance. If the application 
already uses a general-purpose notion of proof of compliance, this 
can be done without having to rethink and re-code the compliance- 
checker. 

1 0 In addition, a general-purpose compliance checker can 

facilitate inter-operability. Requests, policies, and credentials, if 
originally written in the native language of a specific product or 
service, must be translated into a standard format understood by the 
compliance checker. Because a wide variety of applications will each 

1 5 have translators with the same target language, policies and 

credentials originally written for one application can be used by 
another. The fact that the compliance checker can serve as a locus of 
inter-operability may prove particularly useful in e-commerce 
applications and, more generally, in all setting in which public-key 

20 certificates are needed. 

Another possible problem with a compliance-checking 
algorithm is the possibility of self-referencing assertions. For 
example, a digitally signed assertion by party A might represent "I 
approve this request if, and only if, party B approves this request" 

25 while an assertion by party B represents "I approve this request if, and 

only if, party A approves this request." Although this request should 
perhaps be approved, a compliance-checking algorithm may not 
recognize this fact. 

In view of the foregoing, it can be appreciated that a 

30 substantial need exists for a method, solvable in polynomial time and 

10 

SUBSTITUTE SHEET (RULE 26) 

BNSDOCID: <WO 9941878A1J_> 



WO 99/41878 



PCT/US99/0331 1 



widely applicable, that checks the compliance of a request with a 
policy assertion based on credential assertions and solves the other 
problems discussed above. 

5 SUMMARY OF THE INVENTION 

The disadvantages of the art are alleviated to a great extent by 
a method and apparatus for compliance checking in a trust- 
management system. A request r, a policy assertion (/^, POLICY), 

1 0 and n - 1 credential assertions (/*,, s,), . . . , (f n . ,, s n . ,) are received, 

each credential assertion comprising a credential function f; and a 
credential source Each assertion may be monotonic, authentic, and 
locally bounded. An acceptance record set S is initialized to a set of 
the triple {(A, A, /?)}, where A represents an empty portion of the 

15 acceptance record, and R represents the request r. Each assertion (f h 

Sj), where / represents the integers from n - 1 to 0, is run and the result 
is added to the acceptance record set S. This is repeated mn times, 
where m represents a number greater than 1 , and an acceptance is 
output if any of the results in the acceptance record set S comprise an 

20 acceptance record (0, POLICY, R). . 

With these and other advantages and features of the invention 
that will become hereinafter apparent, the nature of the invention may 
be more clearly understood by reference to the following detailed 
description of the invention, the appended claims and to the several 

25 drawings attached herein. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a flow diagram of a method of compliance checking 
for a trust-management system according to an embodiment of the 
5 present invention. 

FIG. 2 is a block diagram of a compliance checker for a trust- 
management system according to an embodiment of the present 
invention. 

10 DETAILED DESCRIPTION 

The present invention is directed to a method and apparatus 
for compliance checking in a trust-management system. A general 
problem addressed by an embodiment of the present invention is 

1 5 Proof of Compliance (POC). The question is whether a "request" r 

complies with a "policy." The policy is simply a function f 0 encoded 
in a programming system or language and labeled by, for example, a 
keyword such as "POLICY." In addition to the request and the 
policy, a POC instance contains a set of "credentials," which also 

20 include general functions. Policies and credentials are collectively 

referred to as "assertions." 

Credentials are issued by "sources." Formally, a credential is 
a pair (f h s s ) of function f x and source identifier (ID) s h which may be 
a string over some appropriate alphabet JJ. Some examples of source 

25 IDs include public keys of credential issuers, URLs, names of people, 

and names of companies. In one embodiment of the present 
invention, with the exception of the keyword POLICY, the 
interpretation of source-IDs is part of the application-specific 
semantics of an assertion, and it is not the job of the compliance 

30 checker. From the compliance checker's point of view, the source- 

12 
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IDs are just strings, and the assertions encode a set of, possibly 
indirect and possibly conditional, trust relationships among the 
issuing sources. Associating each assertion with the correct source- 
ID is, according to this embodiment, the responsibility of the calling 
application and takes place before the POC instance is handed to the 
compliance checker. 

The request r may be a string encoding an "action" for which 
the calling application seeks a proof of compliance. In the course of 
deciding whether the credentials (/j, s } ) 9 . . . , (f n . s n _ } ) constitute a 
proof that R complies with the policy (f 0 , POLICY), the compliance 
checker's domain of discourse may need to include other action 
strings. A request r may include, for example, a request to access or 
copy a data object, or to play a data object that contains, for example, 
audio content. 

For example, if POLICY requires that r be approved by 
credential issuers s { and s 2 , the credentials (/j, s x ) and (f 2 , s 2 ) may 
want a way to say that they approve r "conditionally," where the 
condition is that the other credential also approve it. A convenient 
way to formalize this is to use strings R, R^ and R 2 over some finite 
alphabet J\ The string R corresponds to the requested action r. The 
strings R , and R 2 encode conditional versions of R that might by 
approved by s x and s 2 as intermediate results of the compliance- 
checking procedure. 

More generally, for each request r and each assertion (f j9 s t ), 
there is a set {7?,y} of "action strings" that might arise in a compliance 
check. By convention, there is a distinguished string R that 
corresponds to the input request r. The range of assertion (f h 5,) is 
made up of "acceptance records" of the form (/, s h Ry), the meaning 
of which is that, based on the information at its disposal, assertion 
number /, issued by source s h approves action R iy -. A set of 

13 
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acceptance records is referred to as an "acceptance set." It is by 
maintaining acceptance sets and making them available to assertions 
that the compliance checker manages "inter-assertion 
communication/' giving assertions the chance to make decisions 
based on conditional decisions by other assertions. The compliance 
checker starts with an "initial acceptance set" {(A, A, /?)}, in which 
the one acceptance record means that the action string for which 
approval is sought is R and that no assertions have yet signed off on it 
or anything else. The checker runs the assertions 
(f 0 , POLICY), (/j, 5, (f n . s n . j) that it has received as input, 
not necessarily in that order and not necessarily once each, to 
determine which acceptance records are produced. Ultimately, the 
compliance checker approves the request r if the acceptance record 
(0, POLICY, R), which means "policy approves the initial action 
string," is produced. Note that the use of the string "POLICY" herein 
is by way of example only, and any other information may of course 
be used instead. 

Thus, abstractly, an assertion is a mapping from acceptance 
sets to acceptance sets. Assertion (f v s{) looks at an acceptance set A 
encoding the actions that have been approved so far, and the numbers 
and sources of the assertions that approved them. Based on this 
information about what the sources it trusts have approved, (f b s-) 
outputs another acceptance set A\ 

The most general version of the compliance-checking 
problem, or "proof of compliance," is: given as input a request r and 
a set of assertions (f 0 , POLICY), (f l9 s } \ . . . , (f n . s n . is there a 
finite sequence / 2 , . . . , /, of indices such that each i } is in {0, 1 , . . . 
, n - 1 }, but the ifs are not necessarily distinct and not necessarily 
exhaustive of {0 ; 1, . . . , n - 1 }, and such that: 
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(0, POLICY, R) € (f f , j,) o . . . o (f s ) ({(A, A, R)}) , 



where R is the action string that corresponds to the request r? 

This general version of the problem is mathematically 
undecidable. A compliance checker cannot even decide whether an 
arbitrary assertion (/J, s,-) halts when given an arbitrary acceptance set 
as input, much less whether some sequence containing (//, s,) 
produces the desired output. Therefore, various special cases of POC 
will now be described, including one that is both useful and 
computationally tractable. 

The statement "{(/" 0 , POLICY), (/;, s,), ...,(/; s n . x )} contains 
a proof that r complies with POLICY," means that (r, {(f 0 , POLICY), 

(fu s \)> • • • » ifn- i> s n- 1)}) is a "y es -i nstanc ^" of this unconstrained, 
most general form of POC. If F is a, possibly proper, subset of {(f 0 , 
POLICY), (/*,, ^,), . . . , (f„ m s n „ j)} that contains all of the assertions 
that actually appear in the sequence (f , s .) ° . . . o (f y s.) , then 
"F contains a proof that r complies with POLICY." 

In order to obtain a useful restricted version of POC, various 
pieces of information may be added to the problem instances. 
Specifically, the instance (r, {(f 0 , POLICY), (/J, s x ), ...,(£_ i, s n . 
,)}) may be augmented in one or more of the following ways. 

Global Run Time Bound 

An instance may contain an integer d such that a sequence of 
assertions (f y s ) , . . . , (f. , s . ) is considered a valid proof that r 
complies with POLICY if the total amount of time that the 
compliance checker needs to compute if n s t ) ° . . . ° 
(f. , s . ) ( {(A, A, R)}) is O(A^). Here N is the length of the original 
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problem instance, i.e., the number of bits needed to encode r, (f 0 , 
POLICY), (/j, 5,), - • • ? (f n . i» s n . and d in some standard fashion. 

Local Run Time Bound 

An instance may contain an integer c such that [f. , s ) 
, (f. 9 s.) is considered a valid proof that R complies with POLICY 
if each (f s.) runs in time 0(A^). Here //is the length of the 

actual acceptance set that is input to (f > s .) when it is run by the 

tj if 

compliance checker. Note that the length of the input fed to an 
individual assertion (f f , s.) in the course of checking a proof may 
be considerably bigger than the length of the original problem 
instance (r, POLICY), (/j, s x \ ...,(£_„ c\ because the 

running of assertions (f iy s.) , . . . , (f. y s . ) may have caused 
the creation of many new acceptance records. 

Bounded Number of Assertions in a Proof 

An instance may contain an integer / such that (f.,s) 
> (fi s ) is considered a valid proof if / < /. 

Bounded Output Set 

An instance may contain integers m and S such that an 
assertion (f h can be part of a valid proof that r complies with 
POLICY if there is a set 0, = {/?,,, . . . , R im ) of m action strings, such 
that (f i9 Sj)(A) c O t for any input set A , and the maximum size of an 
acceptance record (/, s h Rfi is S. Intuitively, for any user-supplied 
request r, the meaningful "domain of discourse" for assertion (f h j,) is 
of size at most m - there are at most m actions that it would make 
sense for {f h Sg) to sign off on, no matter what the other assertions in 
the instance say about r. 
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Monotonicitv 

Other variants of POC are obtained by restricting attention to 
instances in which the assertions have the following property: (/J, 57) 
is "monotonic" if, for all acceptance sets A and B, A o. B =~ (f h Sj)(A) 
c (f h Si)(B). Thus, if (f h Sj) approves action when given a certain 
set of "evidence" that /?, is ok, it will also approve R f j when given a 
super-set of that evidence - it does not have a notion of "negative 
evidence." 

Any of the parameters /, /w, and S that are present in a 
particular instance may be written in unary so that they play an 
analogous role to n, the number of assertions, in the 
calculation of the total size of the instance. The parameters dand c 
are exponents in a run time bound and hence may be written in 
binary. 

Any subset of the parameters d, c, /, m, and S may be present 
in a POC instance, and each subset defines a POC variant. Including 
a global run time bound d makes the POC problem decidable, as does 
including parameters c and /. 

In stating and proving results about the complexity of POC, 
the notion of a "promise problem," as discussed in S. Even, A. 
Selman and Y. Yacobi, the "Complexity of Promise Problems with 
Applications to Public-Key Cryptography," Information and Control 
61, pp. 159-174 (1984), may be used. In a standard decision problem, 
a language L is defined by a predicate R in that xe L ^ R(x). In a 
promise problem, there are two predicates, the promise Q and the 
property R. A machine M solves the promise problem (Q, R) if, for 
all inputs for which the promise holds, the machine M halts and 
accepts x if and only if the property holds. Formally, Vx[Q(x) =* [M 
halts on x and M(x) accepts ~ Note that M*s behavior is 

unconstrained on inputs that do not satisfy the promise, and each set 
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of choices for the behavior of M on these inputs determines a 
different solution. Thus, predicates O and R define a family of 
languages, namely all L such that L = L(M) for some Mthat solves 
(fi,*). 

5 The class NPP consists of all promise problems with at least 

one solution in NP. A promise problem is NP-hard if it has at least 
one solution and all of its solutions are NP-hard. To prove that a 
promise problem (Q y R) is NP-hard, it suffices to start with an 
NP-hard language L and construct a reduction whose target instances 
10 all satisfy the promise O and satisfy the property R if and only if they 

are images of strings in L. 

The following are POC variants that can be shown to be NP- 
hard, which is generally interpreted to mean that they are 
computationally intractable in the worst case. 

15 

Locally Bounded Proof of Compliance (LBPOO 

In this case, the "input" is a request r, a set POLICY), (f {i 
* * • > (fn - 1» - j)} °f assertions, and integers c, /, m, and S. The 
"promise" is that each (/J, Sj) runs in time O(A^). On any input set 

20 that contains (A, A, R), where R is the action string corresponding to 

request r, for each (f h sj) there is a set <9, of at most m action strings 
such that (/;, sj) only produces output from O h and S is the maximum 
size of an acceptance record (/, s h where R iy e O v Finally, the 
"question" can be stated as follows: is there a sequence /,,..., /, of 

25 indices such that: 

1 . Each ij is in {0, 1 , . . . , n - 1 } , but the i- need not be distinct 
or collectively exhaustive of {0, 1, .... n - 1 }; 

2. / < / ; and 

3. (0, POLICY, R) s (f ) 0 0 ^ ) ({(A ,A, 



30 /?)})? 
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Globally Bounded Proof of Compliance fGBPOO . 

In this case, the 'input" is a request r, a set {(f Qy POLICY), (f u 
s ]\ * • • > (f n - \ > s n - 1)) °f assertions, and an integer d. The "question" 
can be stated as follows: is there a sequence /,,..., /, of indices such 
that: 

1 . Each ij is in {0, 1, . . . , n - 1 }, but the ij need not be distinct 
or collectively exhaustive of {0, 1, . . . , n - 1 }; 

2. (0, POLICY, 7?) e (/;,,,) 0...0 (f 9 s ) ({(A, A, 
/?)}), where R is the action string corresponding to request r, and; 

3. The computation of (f., s ) ©...<> (f.,s.) ({(A, A, 
/?)}) runs in total time O(A^)? 



Monotonic Proof of Compliance (MPOO 

In this case, the "input" is a request r, a set {(f 0 , POLICY), (/j, 
15 5,), . . . , <f n . l9 s n . ,)} of assertions, and integers / and c. The 

"promise" is that each assertion (f p s,) is monotonic and runs in time 
OiN 0 ). The "question" can be stated as follows: is there a sequence 
/,,..., i ( of indices such that: 

1 . Each ij is in {0, 1 , . . . , n - 1 } , but the / y need not be 
20 distinct or collectively exhaustive of {0, 1, . . . , n - 1 }; 

2. / < / ; and 

3. (0, POLICY, R) e (f n s t ) 0...0 (f s) ({(A, A, 
J?)}), where R is the action string corresponding to request r? 

Each version of POC may be defined using "agglomeration" 
25 (f 2 ? s 2 ) * (/], Sj) instead of composition (f 2 , s 2 ) 0 (f x , s^). The result of 

applying the sequence of assertions (f,s.) , . . . , (f s.) 
agglomeratively to an acceptance set S 0 is defined inductively as 
follows: S, = (/J,, S/iXSo) u S 0 and, for 2</<f,S.H (f > s.) (5.,) u 
Thus, for any acceptance set A, A c (f r s t ) * . . . * 
30 (/" 5.) (>0- The agglomerative versions of the decision problems 
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are identical to the versions already given, except that the acceptance 
condition is "(0, POLICY, R) e (/. , s.) ★ . . . * (f s ) ({(A, 
A, #)})?" As used herein, "agglomerative POC," "agglomerative 
MPOC," etc., refer to the version defined in terms of * instead of <>. 

A trust-management system that defines "proof of 
compliance" in terms of agglomeration can make it impossible for an 
assertion to "undo" an approval that it (or any other assertion) has 
already given to an action string during the course of constructing a 
proof. This definition of proof may make sense if the 
trust-management system should guard against a rogue 
credential -issuer's ability to thwart legitimate proofs. Note that the 
question of whether the compliance checker combines assertions 
using agglomeration or composition is separate from the question of 
whether the assertions themselves are monotonia 

A compliance-checking algorithm according to a preferred 
embodiment of the present invention will now be described. A 
specific case of a POC problem associated with this embodiment will 
be explained. The promise that defines this special case includes 
some conditions that have already been discussed, namely 
monotonicity and bounds on the run time of assertions and on the 
total size of acceptance sets that assertions can produce. According 
to one embodiment of the present invention, however, another 
condition is considered, called "authenticity," which could be ignored 
when proving hardness results. An authentic assertion (f h s^) 
produces acceptance records of the form (/, s h R^), That is, it does 
not "impersonate" another assertion by producing an acceptance 
record of the form (/', s r , R rj \ for / "not equal to /, or si 'not equal to 
si. 

An embodiment of the present invention constructs proofs in 
an agglomerative fashion, and hence * is used in the following 
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problem statement. Note that a variant of POC could be defined 
using © as well. 



Locally Bounded. Monotonic. and Authentic Proof of Compliance 
(LBMAPOO : 

According to this embodiment of the present invention, the 
"input is a request r, a set {{f 0j POLICY), (/j, s x \ . . . , (f n . „ s n . j)} of 
assertions, and integers c, m, and S. The "promise" is that each (f h s,) 
is monotonic, authentic, and runs in time 0(1^). On any input set 
that contains (A, A, R), where R is the action string corresponding to 
request r, for each (f h s y ) there is a set O i of at most m action strings 
such that (f h Sj) produces output from O v Moreover, S is the 
maximum size of an acceptance record (i,-s h R^), such that R^ e O v 
Finally, the "question" can be stated as follows: is there a sequence / l5 
. . . , i ( of indices such that each ij is in {0, 1 , . . . , n - 1 }, but the ij 
need not be distinct or collectively exhaustive of {0, 1, ...,«- 1 }, 
and (0, POLICY, R) e (f n s t ) ★ . . . ★ (f t \, s, ) ({(A, A, *)})? 

Referring now in detail to the drawings wherein like parts are 
designated by like reference numerals throughout, there is illustrated 
in FIG. 1 a flow diagram of a method of compliance checking for a 
trust-management system according to an embodiment of the present 
invention. The flow chart in FIG. 1 is not meant to imply a fixed 
order to the steps; embodiments of the present invention can be 
practiced in any order that is practicable. At step 1 10, a request r, a 
policy assertion (f 09 POLICY) associated with the request r ; and n - 1 
credential assertions (/j, 5,), . . . , [f n , ,, s n . j) are received, each 
credential assertion comprising a credential function f t and a 
credential source s v In addition, an acceptance record set S is 
initialized to {(A, A, R)} at step 1 10, where A represents a 
distinguished "null string" and R represents the inital request, r. 

21 

SUBSTITUTE SHEET (RULE 26) 



WO 99/41878 



PCT/US99/0331! 



At step 120,y is initialized to 1. At step 130 each assertion (f h 
Sj), for integers / from 0 to n - 1 , is run and the result is added to the 
acceptance record set S. If j does not equal mn at step 140, where m 
is a number greater than l y j is increased by 1 at step 150 and step 130 
5 is repeated. 

Ify does equal mn at step 140. it is determined if acceptance 

set S contains an acceptance record, such as (0, POLICY, /?), at step 

160. If not, a rejection is output at step 170. If acceptance set S does 

contain the acceptance record, an acceptance is output at step 1 80. 

10 The following pseudo-code demonstrates the algorithm 

according to one embodiment of the present invention, referred to 

herein as the "Compliance-Checking Algorithm version 1" (CCA!): 

CCA,(r, {(/o, POLICY), (/j, ...,(£.„.*„. ,)>, m): 
{ 

15 {(A. A, R)} 

For j «- 1 to mn 

{ 

For i *- n - 1 to 0 

20 { 



u {{f„ *,)}, Else 5- S u 5' 



If (/;, s,) c /, Then S' - (/J, s^S) 
If IIlFormed((/;, sj)), Then / 



} 



25 } 

If (0, POLICY, R) 6 S, Then Output(Accept), 

Else Output(Reject) 

} 

30 Note that an assertion (f h .s^ is "ill-formed" if it violates the 

promise. If CCAj discovers that (f jy 5,-) is ill-formed, the assertion is 
ignored for the remainder of the computation. An assertion (f h s^) 
may be undetectably ill-formed. For example, there may be sets A e 
B such that (f h S;)(A) & (f h Sj)(B), but such that A and B do not arise in 

35 this run of the compliance checker. The CCA, algorithm may check 
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for violations of the promise every time it simulates an assertion. 
Detailed pseudo-code for these checks is not included in CCA,, 
because it would not illustrate the basic structure of the algorithm. 
Instead, the predicate IllFormed ( ) indicates that the checks may done 
5 for each simulation. 

Like the non-deterministic algorithms discussed above, CCAj 
accepts if and only if the acceptance record (0, POLICY, R) is 
produced when it simulates the input assertions. Unlike the previous 
algorithms, however, it cannot non-deterministically guess an order in 

10 which to do the simulation. Instead, it uses an arbitrary order. CCA, 

also ensures that, if a proper subset F of the input assertions contains 
a proof that R complies with POLICY and every (f i9 e F satisfies 
the promise, then the remaining assertions do not destroy all or part of 
the acceptance records produced by F during the simulation (and 

1 5 destroy the proof), even if these remaining assertions do not satisfy 

the promise. CCA, achieves this by maintaining one set of approved 
acceptance records, from which no records are ever deleted, i.e., by 
agglomerating, and by discarding assertions that it discovers are 
ill-formed. 

20 Note that CCA, does mn iterations of the sequence (f n . , , s n . 

,),..., (/*,, -^iX (fo> POLICY), for a total of mn 2 assertion-simulations. 

Recall that a set F= { (f n s.) , . . . , (f s.) } c {(/~ 0 , POLICY), . 

. . , (f n . s n . ,)} "contains a proof that r complies with POLICY" if 

there is some sequence k ]9 . . . 9 k u of the indices j ]9 . . . ,y„ not 
25 necessarily distinct and not necessarily exhaustive of/,, . . . 9 j (9 such 

that (0, POLICY, R) e (f k ,s k ) (/* , s k ) ({(A, A, R)}). 

Let (r, {(A 0 , POLICY), (/,, 5,) : . . . , tf n _ „*„. ,)}, c, m. s) be an 

agglomerative LBMAPOC instance. As a result: 

1 . Suppose that F c {<f 0 , POLICY), (f t , j,), . . . , (f n . „ s n . ,)> 
30 contains a proof that R complies with POLICY and that every (fj, Sj)e 
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F satisfies the promise of LBMAPOC. Then CCA, accepts (r, {(f Q9 
POLICY), (/,, s x \ ...,(/;.„ s n _ ,)}, c 9 m 9 s) . 

2. If {(f 0 , POLICY), (/,, *,), ...,(£_„ * n _ ,)} does not 
contain a proof that R complies with POLICY, then CCA, rejects (/% 

5 {(/o, POLICY), (/;, 5,), „ 5 n _ ,)}, c, OT , 5) . 

3. CCA, runs in time 0{mn^(nms) ). 

The only non trivial claim above is ( 1 ). Let F = { (f , s .) , . 
• • 9 (/* » ) } be a set that satisfies the hypothesis of (1). Each 
assertion in Fis monotonic, and, as CCA, runs assertions 

1 0 agglomeratively, it never deletes acceptance records that have already 

been produced but rather just adds new ones. Therefore, it may be 
assumed without loss of generality that F contains all of the 
well-formed assertions in {(f 09 POLICY), (/j, s, ),..., (f n _ ,, s n , ,)}. 
Let &,,...,&„ be a sequence of indices, each in {/,,.. . ,7,}, 

1 5 but not necessarily distinct 

and not necessarily exhaustive of {/,, . . . 9 j t } 9 such that (0, POLICY, 
K)e (f* > s > ) * - - • * (ft • s. ) ({(A, A, 7?)}). Assume without 
loss of generality that no sequence of length less than w has this 
property. Let A A u be the acceptance sets produced by applying 

20 (f s k ) , . . . , (f k > s k ) . Because k u ...,*„ is a shortest 

sequence that proves compliance using assertions in F, each set A p 
must contain at least one action string that is not present in any of A 
. . . , A pA . Thus, u iterations of (f Q9 POLICY) * (f u s x ) ★ ...★(/;_ ,, 
■s n . i) would suffice for CCA,. At some point in the first iteration 

25 (f k , s k ) would be run, and because CCA, adds but never deletes 

acceptance records, A , or some super-set of A , would be produced. 
At some point during the second iteration, (f. , s. ) would be run, 

k 2 k l 

and because A , would be contained in its input, A 2 or some superset 
of A-y would be produced. 
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Each (f.,s ) e F satisfies the local boundedness promise, 
producing at most m distinct action strings in any computation that 
begins with {(A, A, R)}. regardless of the behavior of other (even 
ill-formed) assertions. Because |F| = ( < a?, at most mn distinct action 
5 strings can be produced by assertions in F 9 and at most mn sets A p can 

be produced if each is to contain a record that is not contained in any 
earlier set. Thus, u < mn, and mn iterations of (f 0 , POLICY) * (/*,, s x ) 

* -*-*(/n-i>^n-i) suffice. 

Note that cases (1) and (2) do not cover all possible inputs to 

10 CCAj. There may be a subset F of the input assertions that does 

contain a proof that r complies with POLICY but that contains one or 
more ill-formed assertions. If CCA, does not detect that any of these 
assertions is ill- formed, because their ill-formedness is exhibited on 
acceptance sets that do not occur in this computation, then CCA] will 

15 accept the input. If it does detect ill-formedness, then, as 

specified here, CCA, may or may not accept the input, perhaps 
depending on whether the record (0, POLICY, R) has already been 
produced at the time of detection. According to another embodiment 
of the present invention, CCA, is modified to restart whenever 

20 ill-formedness is detected, after discarding the ill-formed assertion so 

* that it is not used in the new computation. The point is simply that 
CCA, should not be given a policy that trusts, directly or indirectly, a 
source of ill-formed assertions. Therefore, the policy author should 
know which sources to trust, and modify the policy if a trusted source 

25 issues ill-formed assertions. 

FIG. 2 is a block diagram of a compliance checker for a trust- 
management system according to an embodiment of the present 
invention. An application 210 running on a user device 200 sends a 
request r to a trust management platform input port 4 1 0 through a 

30 communication network 300 such as, for example: a Local Area 
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Network (LAN), the Public Switched Telephone Network (PSTN), an 
intranet, an extranet or the Internet. A compliance-checking unit 450 
coupled to the input port 410 receives the request along with a policy 
assertion (f 0 , POLICY) associated with the request and n - 1 
5 credential assertions (f,, s, ),..., (f n . s n . ,), each credential 

assertion including a credential function f, and a credential source s v 
Note that the input port 410 may be a single physical input port, or 
several different input ports that may in turn be coupled to different 
networks or other devices. That is, the request, policy and credentials 

10 may not come from the same source or through the same channel. 

The input port 410 is coupled to a compliance-checking unit 
450, which may comprise, for example, the following (not shown in 
FIG. 2): a processing module with a Central Processing Unit (CPU); 
"memories" comprising a Random Access Memory (RAM) and a 

1 5 Read Only Memory (ROM); and a storage device. The memories and 

the storage device may store instructions adapted to be executed by 
the CPU to perform at least one embodiment of the method of the 
present invention. For the purposes of this application, the memories 
and storage device could include any medium capable of storing 

20 information and instructions adapted to be executed by a processor. 

Some examples of such media include, but are not limited to, floppy 
disks, CD-ROM, magnetic tape, hard drives, and any other device 
that can store digital information. In one embodiment, instructions 
are stored on the medium in a compressed and/or encrypted format. 

25 As used herein, the phrase "adapted to be executed by a processor" is 

meant to encompass instructions stored in a compressed and/or 
encrypted format, as well as instructions that have to be compiled or 
installed by an installer before being executed by the processor. 

The compliance-checking unit 450 initializes an acceptance 

30 record set S to {(A, A, /?)}, where A represents a distinguished null 
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string and R represents the request r. The compliance-checking unit 
450 runs assertion (f h s,) for integers / from 0 to n - 1 and adds the 
result of each assertion (f h 57) to the acceptance record set S. This 
process is repeated mn times, where m represents a number greater 
than 1 . The compliance-checking unit 450 may output an 
"acceptance," such as through port 410, or some other 
communication port, if any of the results in the acceptance record set 
S comprise an acceptance record (0, POLICY, R). The compliance- 
checking unit 450 may instead, according to another embodiment of 
the present invention, perform the action R itself. 

Thus, according to one embodiment of the present invention, 
the PolicyMaker system uses a notion of "proof that a request 
complies with a policy" that is amenable to definition and analysis. 
The choice of this notion of proof, however, is a subjective one and 
other notions of proof may also be used. 

In deciding how a set of executable assertions can cooperate 
to produce a proof, a mechanism for "inter-assertion communication" 
of intermediate results may be used. For simplicity, assertions may 
communicate by outputting acceptance records that are input to other 
assertions. More sophisticated interactions, such as allowing 
assertions to call each other as subroutines, might be useful but may * 
require a more complex execution environment. A trade-off might 
therefore exist between the cost of building and analyzing such an 
execution environment and the potential power to be gained by using 
more sophisticated interactions to construct proofs of compliance. 

The choice of a simple communication mechanism implies 
that a part of constructing a proof of compliance is choosing an order 
in which to execute assertions. According to an embodiment of the 
present invention, the responsibility of choosing this order rests with 
the compliance checker and not, for example, the calling application. 
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Although the compliance checker's job could be made easier by 
requiring the calling application to give it the correct order as an 
input, such a requirement may not be consistent with the system's 
overall goals. For example, applications may need to use credentials 
5 issued by diverse and far-flung sources without having to make 

assumptions about the order in which these credentials communicate 
via acceptance records. In an extreme case, the issuing sources may 
not be aware of each others' existence, and no such assumptions by 
the calling application would be valid. Although the most general 
1 o version of the POC problem allows assertions to be arbitrary 

functions, the computationally tractable version may only be correct 
when all assertions are monotonic. 

In particular, according to one embodiment of the present 
invention, monotonic policy assertions may produce a correct result, 
1 5 and this excludes certain types of policies that are used in practice, 

including those that use "negative credentials" such as revocation 
lists. Despite this restriction, the monotonicity requirement has 
certain advantages. Although the compliance checker may not handle 
all potentially desirable policies, it is at least analyzable and provably 
20 correct on a well-defined class of policies. Furthermore, the 

requirements of many non-monotonic policies can often be achieved 
by monotonic policies. For example, instead of requiring that an 
entity not appear on a revocation list, the system may require a 
"certificate of non-revocation." The choice between these two 
25 approaches involves trade-offs among the (system-wide) costs of the 

two kinds of credentials and the benefits of a standard compliance 
checker with provable properties. Moreover, restriction to monotonic 
assertions encourages a conservative, prudent approach to security. 
In order to perform a potentially dangerous action, a user must 
30 present an adequate set of affirmative credentials. Potentially 

28 

SUBSTITUTE SHEET (RULE 26) 

BNSDOCID: <WO 9941B7BA1_I_> 



WO 99/41878 



PCT/US99/03311 



dangerous action are not allowed "by default," simply because of the 
absence of negative credentials. 

According to an embodiment of the present invention, the 
POC problem has been formulated in a way that allows assertions to 
5 be as expressive as possible. As a result, well-formedness promises 

such as monotonicity and boundedness, while formal and precise, 
may not be verified. Each assertion that conditionally trusts an 
assertion source for application-specific expertise (such as suitability 
for a loan) must also trust that source to write bounded and 
10 monotonic assertions and to trust other similar sources of assertions. 

The resulting notion of soundness is that if there is no proof from a 
set of trusted, well-formed assertions, then CCA, will not accept the 
input. 

Full expressiveness, however, is just one goal of a trust- 
15 management system. Another 

goal is the clear separation of the trust relationships of assertions 
from programming details. 

To some extent, these goals are at odds — the compliance checker may 
not perform verifications on fully general programs, and thus an 

20 assertion writer may need to worry about some programming details. 

Note that monotonic assertions may actually be written as, for 
example, AND-OR circuits and bounded assertions may actually 
"declare" the finite set from which they will produce output. A 
compliance-checking algorithm could then easily detect the ^ 

25 ill-formed assertions and discard them. This would free assertion 

writers of the burden of deciding when another writer is trusted to 
write bounded and monotonic code, just as requiring assertions to be 
written in a safe (and therefore restricted) language frees the assertion 
writer from worrying about certain application-independent 

30 programming details. This verifiability comes at a price: listing a 
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finite output set is relatively inexpensive, but there are monotonic 
functions that require exponentially bigger circuits to express over a 
basis of AND and OR than they require over a basis of AND, OR, 
and NOT. See, E. Tardos, "The Gap Between Monotone and Non- 
monotone Circuit Complexity is Exponential," Combinatorica 8, pp. 
141-142 (1988). In some applications it may be cheaper, on average, 
to write assertions that are verifiably bounded and monotonic than to 
determine the set of sources trusted (even indirectly) by a given 
assertion and to judge whether they are trusted to be monotonic and 
bounded. 

According to another embodiment of the present invention, 
the compliance checker makes the original code of an assertion that 
produced a record available to other assertions reading that 
acceptance record. A conservative policy then, before trusting 
assertions (fi,s } ) and (f 2 > s 2 ), could require and check that f x andf 2 be 
verifiably monotonic and bounded and that f x and^ each include 
specific standard code to check all assertions whose acceptance 
records (/j, s x ) and (f 2 , s 2 ) wish to trust. A complex monotonic 
assertion that needs to be written compactly using NOT gates can, if 
desired, still be used with the modified compliance algorithm. 

Although various embodiments are specifically illustrated and 
described herein, it will be appreciated that modifications and 
variations of the present invention are covered by the above teachings 
and within the purview of the appended claims without departing 
from the spirit and intended scope of the invention. For example, 
although specific pseudo-code was used to describe one embodiment 
of the present invention, it will be understood that other compliance- 
checking algorithms will also fall within the scope of the invention. 
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What is claimed is : 

1 1 . A method of compliance checking in a trust-management 

2 system, comprising: 

3 a) receiving a request r, a policy assertion (f 0 , POLICY) 

4 associated with the request /% and n - 1 credential assertions (/j, s,), . . 

5 • , (f n . t> s n • iX eac h credential assertion comprising a credential 

6 function f t and a credential source sf, 

7 b) initializing an acceptance record set S to {(A, A, R)}, where 

8 A represents an empty portion of the acceptance record set S, and R 

9 represents the request r; 

10 c) running assertion (f h Sj) on the acceptance set S for each 

1 1 integer / from n - 1 to 0 and adding the result of each assertion (f h s t ) 

12 to the acceptance record set S; 

13 d) repeating step (c) mn times, where m represents a number 

1 4 greater than 1 ; and 

15 e) determining if the acceptance record set S includes (0, 

16 POLICY, R). 

1 2. The method of claim 1, further comprising: 

2 f) determining whether an assertion (f h j,) is ill-formed; 

3 wherein step (c) is only performed for assertions (f h j ; ) that 

4 are not ill-formed. 

1 3. The method of claim 2, further comprising: 

2 g) initializing a set / to an empty set; and 

3 h) adding any ill-formed assertions (f h to set /. 

1 4. The method of claim 1 , wherein a request r is a request to 

2 access a data object. 
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1 5. The method of claim 1, wherein a request r is a request to 

2 make a copy of a data object. 

1 6. The method of claim I , wherein a request r is a request to 

2 play a data object that includes audio content. 

1 7. The method of claim 1 5 wherein a credential function 

2 includes a subject, an action, and an object. 

1 8. The method of claim 1, wherein the request r is a string 

2 encoding an action for which a calling application seeks a proof of 

3 compliance. 

1 9. The method of claim 1, wherein R represents an action 

2 string corresponding with the request r. 

1 1 0. The method of claim 9, wherein the action string R 

2 includes a subject, an action and an object. 



1 1 . The method of claim 1 , wherein a credential assertion 
includes one of a public key, a uniform resource locator and a name. 



1 12. The method of claim 1 , wherein credential function yj is 

2 correlated with a credential source s i by cryptographically signing the 

3 credential function f t with a private cryptographic key belonging to 

4 credential source 5,. 



1 13. The method of claim 1, wherein each assertion is 

2 monotonic, authentic, and locally bounded. 
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1 14. A method of compliance checking in a trust-management 

2 system^ comprising: 

3 a) receiving a request; 

4 b) receiving a policy associated with the request; 

5 c) receiving a number of credentials, the policies and 

6 credentials comprising a number of monotonic, authentic, and locally 

7 bounded assertions; and 

8 d) deciding whether the credentials prove that the request 

9 complies with the policy. 

1 1 5. The method of claim 14, wherein a monotonic assertion 

2 approves an action when provided with a set of evidence if the 

3 assertion would approve the action when provided with a subset of 

4 that evidence. 

1 16. The method of claim 14, wherein an authentic assertion 

2 produces acceptance records that do not impersonate another 

3 assertion. 

1 17. The method of claim 14, wherein a locally bounded 

2 assertion is bounded in terms of a maximum runtime and a maximum 

3 size of acceptance sets that can be produced. 

1 18. The method of claim 14, wherein the policy comprises a 

2 function^ encoded in a programming system 

1 19. A method of compliance checking in a trust-management 

2 system, comprising: 

3 receiving (i) a request r to perform an action R and (ii) 

4 assertions (/~ 0 , POLICY), (/",, s } ) 9 ...,(/;.,, s„_ ,); 
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5 executing, mn times, assertion (f h for each integer / from n 

6 - 1 to 0, the execution being performed using any information 

7 generated by previously executed assertions, m representing a number 

8 greater than 1 ; and 

9 determining if (0, POLICY, R) has been generated. 

1 20. An apparatus for compliance checking in a trust- 

2 management system, comprising: 

3 a processor; and 

4 a memory storing instructions adapted to be executed by said 

5 processor to receive a request R to perform an action and assertions 

6 (f 0 , POLICY), (/*,, . . . , (f n _ s n _ ,), initialize an acceptance record 

7 set S to {(A, A, R)} , where A represents a distinguished null string, 

8 iteratively run, mn times, assertion (f iy j y ) on the acceptance set S for 

9 each integer / from n - 1 to 0 and add the result of each assertion (f i9 

1 0 sj) to the acceptance record set S 9 where m represents a number 

1 1 greater than 1 , and determine if the acceptance record set S includes 

12 (0, POLICY, R). 
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1 21 . A trust management platform, comprising: 

2 an input port configured to receive a request, a policy 

3 assertion (f Q , POLICY), and credential assertions (/j, s } ),..., (f n _ { , s n 

4 . ,), each credential assertion comprising a credential function f x and a 

5 credential source and 

6 a compliance checking unit coupled to said input port and 

7 configured to: 

8 a) initialize an acceptance record set S to {(A, A, R)}, 

9 where A represents a distinguished null string and R 

1 0 represents information corresponding with the request, 

1 1 b) run assertion (f h s,) on the acceptance set S for each 

12 integer / from n - 1 to 0 and add the result of each assertion (f h 

1 3 5,-) to the acceptance record set 5, 

1 4 c) repeat step (b) mn times, where m represents a 

1 5 number greater than 1 , and 

1 6 d) determine if acceptance record set S includes an 

1 7 acceptance record (0, POLICY, R). 

1 22. A trust-management system, comprising: 

2 means for receiving a request to perform an action r and a set 

3 of assertions (f 0 , POLICY), (/j, 5^, ...,(/;.,, ,); and 

4 means for proving that the request r is consistent with the set 

5 of assertions. 
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1 23. A medium storing instructions adapted to be executed by 

2 a processor to perform steps including: 

3 a) receiving a request r, a policy assertion (f Q , POLICY) 

4 associated with the request r, and n - 1 credential assertions (/J, s^, . . 

5 . , (f n _ s n _ ,), each credential assertion comprising a credential 

6 function f t and a credential source s$> 

7 b) initializing an acceptance record set S to {(A, A, R)} , where 

8 A represents a distinguished null string and R represents the request r; 

9 c) running assertion (f h Sj) on the acceptance set S for each 

1 0 integer / from n - 1 to 0 and adding the result of each assertion (f h 57) 

1 1 to the acceptance record set S; 

12 d) repeating step (c) mn times, where m represents a number 

1 3 greater than 1 ; and 

14 e) determining whether the acceptance record set S includes 

15 (0, POLICY, R\ 

1 24. A method of compliance checking in a trust-management 

2 system, comprising: 

3 a) receiving a request r, a policy assertion (f 0 , POLICY) 

4 associated with the request r, and n - 1 credential assertions (/",, s } ), . . 

5 . , (f n _ j, s n . ,), each credential assertion comprising a credential 

6 function f t and a credential source 5,; 

7 b) initializing an acceptance record set S to {(A, A, i?)}, where 

8 A represents a distinguished null string and R represents the request r; 

9 c) for each integer / from n - 1 to 0: 

1 0 running assertion 0/, s,) against the acceptance set S 

1 1 and adding the result to the acceptance record set S, 

12 determining if the acceptance record set includes (0, 

13 POLICY, R), and 
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14 if the acceptance record set includes (0, POLICY, 

15 then stopping said method; and 

16 d) repeating step (c) mn times, where m represents a number 

17 greater than 1. 

1 25. A method of compliance checking in a trust-management 

2 system, comprising: 

3 a) receiving credential assertions (/j, s,), . . . , (f n . l9 s n . ,), 

4 each credential assertion comprising a credential function f t and a 

5 credential source s,; 

6 b) initializing an acceptance record set S to {(A, R)}^ where A 

7 represents an empty portion of the acceptance record set S t and R 

8 represents a request; 

9 c) running assertion (f h Sj) on the acceptance set S for each 

10 integer / from n - 1 to 0 and adding the result of each assertion (f h 

1 1 to the acceptance record set S; 

12 d) repeating step (c) mn times, where m represents a number 

1 3 greater than 1 . 
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